1. Technical Field
The present invention relates generally to computer software and more specifically to methods for facilitating business to business interactions in electronic commerce.
2. Description of Related Art
Automating business to business interactions is an important problem in electronic commerce. With the increase in the automation of internal business processes of organizations, there is a demand for building systems to address the issues of seamlessly automating long running business to business interactions. Several approaches have been adopted to address this problem.
Currently, there are peer business applications that interact through simple request/response interactions. The communications between the businesses are guided by well defined protocols for exchanging the requests and responses. The request/response interactions may be either synchronous or asynchronous. An example of a synchronous interaction could be a HTTP request by one business, which triggers a business process inside the peer business system and finally gets a response when the processing of the request is completed. Alternatively, asynchronous requests and responses are sent as separate messages, i.e., the server processes a request asynchronously, and sends a response back to the requester.
For example, referring to FIG. 1, a block diagram of a typical prior art business-to-business interaction is depicted. In the prior art, a business A 102, implemented as a data processor, sent a request 106 to business B 104, also implemented as a data processor. Business B 104 then sent an acknowledgment 108 back to business A 102 and then a response 110. The second request 112 is then sent from business A 102 to business B 104. This second request 112 may depend on the results of the response 110 to the first request 106. Business B 104 then sends an acknowledgment 114 back to business A 102 and then a response 116 after the request 112 has been processed.
Electronic service contracts help simplify the setting up of long standing business relationships. Electronic service contracts may define either synchronous or asynchronous processes. Synchronous refers to events that are synchronized, or coordinated, in time, whereas, in contrast, asynchronous refers to events that are not synchronized, or coordinated, in time. An example of asynchronous interaction could be requests made using the Coyote Business Process Framework as described in U.S. Pat. No. 6,148,290 which is hereby incorporated herein by reference for all purposes. Contracts explicitly specify the messages that are exchanged for requests and responses. The Coyote business process framework provides a base for setting up and conducting long running asynchronous transactions.
All of the approaches described above require the exchange of several messages back and forth for each process (each process may include multiple requests) before a desired result could be achieved. Typically an alternative action or a successive action is requested only after the results of the preceding action are known to the requesting business. This results in long delays and longer connectivity between the partners.
Thus, for example, business A 102 may be an agent purchasing airline tickets and hotel accommodations for a traveler. However, suppose the traveler is unwilling to travel unless airline tickets are obtained for less than a specified amount. Business A 102 must then await the response related to the request for airline tickets before submitting the request for hotel accommodations. However, such a wait is time consuming and also may result in hotel accommodations at a preferred location becoming unavailable during periods of high demand.
Among the other models that address the business to business interactions are mobile agents that are dispatched from one business to another. The mobile agents are software defined by a programming language or a scripting language which can be executed or interpreted by the node at which the agent is deployed. The peer business system then executes the logic packaged into the mobile agent and then responds with the results of the actions.
Prior art approaches to solve this problem have tried to use mobile agent technology as shown in FIG. 2. In this case, mobile agents 206 and 208, which are arbitrary programs written in high-level programming languages, contain the logic for generating multiple requests 210 to be performed by business B 204, the decision logic to be adopted after the outcome of each action, as well as generating the final responses 212. There are many problems however with this scenario as illustrated by Stefan Pleisch in IBM Research Report RZ 3152 State of the Art of Mobile Agent Computing—Security, Fault Tolerance, and Transaction Support, IBM Zurich Research Lab, 1999.
First, there is the problem of persistence and fault-tolerance. The mobile agent depends on the mobile agent execution system to provide persistent storage and tolerance to faults. This is especially essential in an ecommerce setting since ecommerce interactions are typically long-running and may take days or even weeks. However, the state to be made persistent in mobile agents is not explicitly defined and it is difficult for a server business to give any kind of guarantees.
Second, there is the problem of transaction support. Ecommerce interactions often require ACID transaction guarantees or possibly weaker transaction guarantees across multiple requests (may use compensating transactions). Again, the mobile agent execution system would have to provide these support to the mobile agent. This is difficult to do since the server system does not have an explicit understanding of the mobile agent code.
Third, there is the problem of resource control. An arbitrary piece of Java code may invoke any actions in an uncontrolled manner leaving the mobile agent execution system responsible for determining the access control policies. Again, this is difficult to achieve in a mobile agent setting because of the lack of well-defined, mutually-agreed-on policies (contracts) between the server and client.
Fourth, there is the problem of complexity. Writing a mobile agent is a non-trivial task requiring programming in a programming language. It is also procedural rather than declarative in style (for mobile agents written in imperative languages). The business logic may not require this full complexity and it does not make the composition semantics explicit as in a declarative style.
Therefore, it would be desirable to have a system and data structure for processing service requests such that recovery of previous steps is possible after failure and, additionally, in a manner that does not compromise the security of the computer receiving the requests.